I wrote about cloud connections when they were in a very early stage.
Cloud connections evolved and are now sharable. We call the “regular” connection as “personal connection”.
The problem with the “personal connections” is the difficult to make teamwork. The personal connections belong to you and different developers can’t use them. When a different developer needs to work with the same objects, they are required to create their own connection.
Using cloud connections, we can create a single, reusable connection to the data source and share it with all the developers in the team.
Creating a Cloud Connection
In the semantic model settings, we usually make the configuration using the Data Source Credential settings.
We can use the Gateway and cloud connections area to replace the personal connection by a cloud connection. We can create a new cloud connection, defining the authentication to the data source.
This is done in two steps: First, you create the connection object. After that, you select the connection object in the Gateway and cloud connections area.
Cloud Connection and Direct Query
The Cloud connection using OAUTH authentication can be a great benefit for direct query connections.
Direct query would require the end user to have access to the source of the information. However, how could we ensure the user has access only to the report and the information provided to the report and not to the source?
Cloud connections are the solution. Creating a cloud connection with a defined OAUTH authentication to the source, this authentication is the responsible to access the source. The source has no knowledge of the end user and the end user will only have access to the report, not anything else.
Sharing Cloud Connections
We can manage all the connections using Settings -> Cloud Connections and Gateways. We are moving from a stage when cloud connections were not sharable. As a result, you may find hundreds of auto-created connections in this area.
You will need to spend some time replacing old auto-created connections by shared connections.
Once we created the connections, we can define who can use the connection using the menu item Manage Users.
You can give permission to specific developers, or you can build a group of developers in Azure AD and set the permissions to the group.
Hidden Authentication Information from Developers
The creation of a connection object which is shareable to the developers suggests the possibility to hide from the developers the details of the connections.
However, it’s not so simple. The challenge is that we can’t change the target of the connection in the semantic model. A cloud connection will be pointing to the target already set up in the semantic model.
The developer is the one who creates the connection using Power BI Desktop. In this way, the developer already has authorization to access the target server anyway. In this way, there isn’t much benefit from using a connection object the developer doesn’t control, because he already has a different authentication for the server.
The secret is to use the Cloud Connections together deployment pipelines in a well-planned development lifecycle.
The developer will always have access to the development sources, this is inevitable. However, when the semantic model is promoted from DEV to TEST, a deployment pipeline rule can change the target of the connection.
After the target is changed, you can create a cloud connection for the new target. The developer may need permission to use the connection to setup the semantic model, but he doesn’t need to know the authentication details.
In this way, if the environment is well organized the developer only need to know the authentication for development sources. The other ones are optional.
Summary
The new features of the Cloud Connections improve the level of the development lifecycle in the Microsoft Fabric environment
Load comments